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Abstract 

In various scenarios, there is a need to expose a certain API to 
client programs which are not fully trusted. In cases where the 
client programs need access to sensitive data, confidentiality can 
be enforced using an information flow policy. This is a general 
and powerful type of policy that has been widely studied and 
implemented. 

Previous work has shown how information flow policy enforce- 
ment can be implemented in a lightweight fashion in the form of 
a library. However, these approaches all suffer from a number of 
limitations. Often, the policy and its enforcement are not cleanly 
separated from the underlying API, and the user of the API is ex- 
posed to a strongly and unnaturally modified interface. Some of the 
approaches are limited to functional APIs and have difficulty han- 
dling imperative features like I/O and mutable state variables. In 
addition, this previous work uses classic static information flow en- 
forcement techniques, and does not consider more recent dynamic 
information flow enforcement techniques. 

In this paper, we show that information flow policies can be 
enforced on imperative-style monadic APIs in a modular and rea- 
sonably general way with only a minor impact on the interface pro- 
vided to API users. The main idea of this paper is that we imple- 
ment the policy enforcement in a monad transformer while the un- 
derlying monadic API remains unaware and unmodified. The pol- 
icy is specified through the lifting of underlying monad operations. 

We show the generality of our approach by presenting imple- 
mentations of three important information flow enforcement tech- 
niques, including a purely dynamic, a purely static and a hybrid 
technique. Two of the techniques require the use of a generalisation 
of the Monad type class, but impact on the API interface stays lim- 
ited. We show that our technique lends itself to formal reasoning by 
sketching a proof that our implementation of the static technique is 
faithful to the original presentation. Finally, we discuss fundamen- 
tal limitations of our approach and how it fits in general information 
flow enforcement theory. 

Categories and Subject Descriptors D.4.6 [Security and Protec- 
tion] : Information flow controls 

General Terms Security, Languages 

Keywords information flow enforcement, monads, monad trans- 
former, parameterised monads 
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1. Introduction 

In various scenarios, there is a need to expose a certain API to a 
program without fully trusting it. Examples are JavaScript appli- 
cations running in a web browser, plug-ins in user applications or 
even independent programs in a general-purpose OS. In order to 
protect against faulty or malicious use of the API, policies are de- 
fined establishing what constitutes valid use of the API. Such a pol- 
icy is then enforced statically (type systems or other compile-time 
analysis) or dynamically (run-time monitoring). 

Information flow policies are an important general class of poli- 
cies. Given an ordered set of security levels, and a classification of 
all input and output operations at certain security levels, such a pol- 
icy mandates that input at a certain security level must not in any 
way influence output at lower security levels. In the common case 
with only two security levels, secure information flow mandates 
that confidential information does not leak to public outputs. 

It has been shown [13, 19, 22] that enforcement of information 
flow policies can be implemented in a lightweight fashion in the 
form of a library. However, these approaches suffer from a number 
of limitations. Often, the policy and its enforcement are not cleanly 
separated from the underlying API, and the user of the API is 
exposed to a strongly and unnaturally modified interface. Some of 
the approaches are limited to functional APIs and have difficulty 
handling imperative features like I/O and mutable state variables. 
In addition, all of these libraries use a form of static analysis 
(either at compile-time or at runtime). None of them show how to 
implement the dynamic information flow enforcement techniques 
that are increasingly being studied in information flow research 
[2, 4, 12, 21]. 

In this paper, we present a general technique for enforcing in- 
formation flow policies in monadic libraries in Haskell. The en- 
forcement of the policy occurs in a monad transformer, wrapping 
the monadic API of the underlying library, which remains unaware 
and unmodified. Policies are specified through the lifting of base 
monad operations into the transformed monad. We show that our 
technique is suited for implementing a wide range of enforcement 
techniques, including dynamic, static and hybrid ones. We show 
that this is possible while maintaining most of the "look and feel" 
of the underlying monadic library API. 

Contrary to previous work, we do not limit ourselves to infor- 
mation flow enforcement techniques based on static analysis. We 
present implementations of three important information flow en- 
forcement techniques, including a purely dynamic, a purely static 
and a hybrid technique. The two latter techniques require some 
form of static analysis of user code, which we implement using 
a generalisation of the Monad concept, called parameterised mon- 
ads [9]. This allows us to type the monadic operations return, (;>) 
(sequence) and (bind) differently, allowing us to perform 

the static analysis we need without relying on explicit developer- 
provided casts. 



In section 7, we provide a formal result and a proof sketch 
demonstrating the faithfulness of our account of Volpano et al.'s 
classic type system-based enforcement [24], which we implement 
in section 6. We show that we can translate programs in a model 
language extended with output statements to calculations in our 
monad transformer, where the typing judgements of a straightfor- 
ward extension of Volpano et al.'s type system correspond in a 
precisely defined manner to the types of our transformed monad 
calculations. We do not expect corresponding results for our other 
implementations to be significantly harder to formulate and prove. 

Finally, we look into the limits of our approach. In the context 
of dynamic information flow enforcement, we can think of our 
approach as a type of monitor where the monitorable events are 
the monadic sequence (>•) and bind (S=) operators. We discuss 
that for at least one recent dynamic information flow enforcement 
technique [2], these monitorable events do not suffice, making it 
impossible to implement the technique as a monad transformer. 

In summary, the contributions of this paper are: 

• We propose an approach to implementing information flow 
policy enforcement for monadic libraries. Contrary to existing 
work, it allows for a clean separation between policy enforce- 
ment and the underlying API, and does not impose unnatural 
modifications of the interface provided to users of the library. 

• We provide evidence for the generality of the approach by pre- 
senting implementations of three information flow enforcement 
techniques, including a dynamic, a static and a hybrid tech- 
nique, where existing libraries only work with static analysis. 
We are not aware of any previous implementations of dynamic 
information flow enforcement as a library. 

• We give a formal statement of the faithfulness of our account of 
a static enforcement technique to the original presentation, and 
provide a proof sketch. 

• We discuss the limitations of our approach, in which all 
compile-time or run-time interception takes place at the level 
of monadic operations, making it unsuitable for at least one 
dynamic enforcement technique [2]. 

2. The basic idea 

In order to explain the basic design of our library, we show an ex- 
ample of a monadic API on which we want to enforce an informa- 
tion flow policy. 

2.1 An E-mail Client Example 

Our example API starts from a simplistic scenario where an e- 
mail application provides a plug-in infrastructure allowing user- 
or institution-provided plugins to intercept e-mails while they are 
being sent. Plug-ins are allowed to modify e-mails (e.g. in order 
to add quotes or disclaimers at the bottom of the e-mail), send the 
mail to multiple recipients (e.g. to the original recipient and to an 
archiving system). In order to do this, they are allowed to retrieve 
external resources (e.g. a company standard disclaimer or a quotes 
database), identified by URLs. 

In order to prevent malicious plug-ins from leaking users' pri- 
vate information through resource requests, an information flow 
policy is defined. The result of any readMail operation is consid- 
ered confidential information, and it is only allowed to influence 
sendMail operations, which are considered as output at the con- 
fidential security level (note that malicious plug-ins could send e- 
mails to other recipients than the original, but we assume for sim- 
plicity that this is prevented in some other way). Invocations of 
downloadResource and the URLs passed to them are considered 
public, as they can be observed on the network or by the resource 
server owners. The result of downloadResource calls is public in- 



class (Monad to) => EmailM m where 
readMail :: m String 
sendMail :: String — >• m () 
downloadResource :: String — > to String 

instance EmailM 10 where 

sendMail — putStrLn o ("Sending mail: "4f) 
readMail = putStr " : " >> getLine 
downloadResource — (^return "prefix; ") o 
putStrLn o ("Downloading resource: "-ff) 

instance (EmailM m) => EmailM (StateT a m) where 
sendMail — lift o sendMail 
readMail — lift readMail 
downloadResource = lift o downloadResource 



Figure 1. An example API presented to plug-in developers in an e- 
mail application, along with an example implementation in the IO 
monad. We also provide classic automatic lifting of the EmailM 
operations through the state monad transformer. 

formation. With this classification of base monad operations at se- 
curity levels, an information flow policy is defined, stating that the 
contents of a user e-mail must not in any way influence requests for 
external resources. In further sections, we show how to specify and 
enforce this policy using different enforcement monad transform- 
ers. 

The API presented to plug-in developers is shown in Figure 1. 
The API is defined in the EmailM type class. This type class 
extends the Monad type class and provides readMail, sendMail 
and downloadResource operations. The readMail operation re- 
turns the contents of a mail input by the user, the sendMail oper- 
ation ships off a mail to be sent and the downloadResource op- 
eration takes the URL of a resource and returns its contents. The 
figure also shows a model implementation in the IO monad and 
an automatic lifting of the EmailM type class through a StateT 
monad transformer (similar to how this is done with e.g. the stan- 
dard MonadReader type class). 

2.2 Information flow enforcement in a Monad transformer 

The basic observation behind our implementation approach for 
information flow enforcement libraries is that in a monadic API, 
a lot can be learned about the program's information flow from the 
invocations of Monad operations ;> and For example, when 
two calculations a and b are sequenced (a^> b), we are sure that the 
result value of a can not influence computation b. On the contrary, 
when a monadic calculation a is bound to a continuation/ (a^=f), 
we can interpret this as a generalised form of a branching statement, 
where the result value of a determines the calculations that will be 
executed next. 

The next observation we make is that intercepting monadic 
operations in a base monad is precisely what Haskell's Monad 
transformers allow us to do. And with this second observation, 
the basis of our approach is clear: we will implement information 
flow enforcement techniques as monad transformers and use the 
information we can obtain from intercepted Monad operations to 
approximate the flow of information in a program. 

There is one important problem with this approach however, 
namely that the calls to Monad operations do not always correctly 
represent the actual information flow in a program. For example, 
in the program do x <— getLine; return (), it would be wrong 
to assume that the result of getLine influences the result of the 
combination. Nevertheless, a Haskell compiler will "desugar" the 
example to getLine ^= Xx — > return (), and our monad trans- 



badflow = do sec <— getSec 
putSecret sec 
pub <— getPub 

putPublic $ pub -H- " , done . " 

goodflow = do sec <— getSec 
putSecret sec 
3> do pub <— getPub 

putPublic $ pub -ff " , done . " 



Figure 2. An example requiring non-standard use of the do- 
notation to provide proper scoping information for use in the in- 
formation flow enforcement. In the expression badflow it will not 
be clear to the enforcement transformer that the information com- 
ing from getSec is not used in the call to putPublic. The scoping 
in the expression goodflow makes this clear. 

formers will have to assume that the result value of getLine is used 
by the function Ax — > return (), leading to an overapproximation 
of the information flow in the program. The solution we will adopt 
to this problem is that we impose the requirement on users of the 
API to accurately reflect the flow of sensitive information in their 
programs through a proper scoping of variables. For example the 
example above should instead be written as do getLine; return () 
or getLine ^> return (). In this case, the use of S> instead of 
allows the enforcement technique to detect that the result of the left- 
hand side calculation is not used in the other one. Figure 2 shows 
a more complicated example where two separate do-statements are 
explicitly sequenced to correctly reflect the example's information 
flow in the structure of the Monad operation calls. 

Note that a consequence of this approach is that we do not 
treat a sequence of two calculations ma >- mb as identical to 
ma 3= const mb, contrary to what Haskell programmers are used 
to. However, we want to point out that sematically identical con- 
structs are often treated differently by information flow enforce- 
ment techniques. Consider how x := s — s would be treated dif- 
ferently from x :— 0 by most techniques or how if sec then x := 
true else x := false would be treated differently from x := sec 
by Austin and Flanagan's enforcement technique [2]). This impre- 
cision is inherent to enforcement techniques employing the syntac- 
tic structure of programs, rather than their actual behaviour. De- 
vriese and Piessens have recently presented a fundamentally differ- 
ent technique which does not suffer from this problem [4]. 

2.3 Telling the good from the bad 

Figures 3 and 4 show examples of plug-ins using the EmailM 
interface. Both employ explicit sequencing of two separate do- 
statements, as discussed in the previous section. We will use these 
examples throughout this paper to demonstrate our implementa- 
tion. 

The first example (pluginl) shows a plug-in which prefixes 
the user mail with the contents of an external resource, appends a 
newline and sends the mail. No information about the mail leaks 
to the resource server, so this plug-in respects the information 
flow policy. On the other hand, plugin2 will only download the 
external resource if a certain property holds for the user e-mail, 
thus violating the policy: the owner of the resource server can de- 
duce that the user sent a mail satisfying the islnteresting prop- 
erty. Note that in this case, information is only leaked because the 
request for the external resource is issued in a branch on secret 
data, which is sometimes called an "implicit" leak in the infor- 



res :: String 

res = "http://example.com/res.txt" 

pluginl :: (EmailM m, MonadState String m) => m () 
pluginl — do m ^— readMail 

put$m-^ "\n" 
> dop downloadResource res 

m 4— get 

sendMail $p-(fm 



Figure 3. Example plug-in pluginl , respecting the information 
flow policy. 

islnteresting :: String — > Bool 
islnteresting — elem "Haskell" o words 
plugin2 :: (EmailM m, MonadState String m) => m () 
pluginZ =doraf- readMail 
put$m-Ur "\n" 
>> do m get 

if islnteresting m 

then downloadResource res 
else return " " 
sendMail m 



Figure 4. Example plug-in plugtn2, which does not respect the 
information flow policy, because it leaks information about the user 
mail to the external resource server. 

mation flow literature. If we replace the if-then-else block with 
downloadResource $ res 4f "?q=" -ff escape m, then there is 
an "explicit" leak of information. 

With these two examples, we have set the objective for the 
rest of this text. In the next sections, we implement three different 
monad transformers, implementing information flow enforcement 
techniques to be able to detect illegal information flows, such as 
the one in plugin2 without interfering with correct plug-ins like 
pluginl . 

3. Dynamic information flow enforcement with 
security level ascriptions 

The first information flow enforcement technique we implement 
is Sabelfeld and Russo's simple flow-insensitive dynamic enforce- 
ment [21]. They employ a fixed programmer-provided assignment 
of security levels to variables. With this information, they can de- 
duce a security level for each expression, and track the security 
level of all information in the program. In order to prevent im- 
plicit leaks, they additionally keep a stack of security levels for 
the "program counter", representing the maximum security level of 
all information that determined the currently executing branch to 
be chosen. This allows them to detect implicit information leaks 
when public output is produced in a branch whose execution was 
determined by confidential information. It's a simple technique, so 
we do not go further into the details, but we think they will quickly 
become clear in our implementation. 

Before we start, we need a type to represent security levels at 
run-time. 

data DynSL — L | H deriving (Show, Eq, Ord) 

In order to implement Sabelfeld and Russo's monitor in a 
monad, we represent a calculation in the monad as a function of 
type DynSL — > m (DynSL, a). The calculation takes as input the 



current security level of the program counter, executes in the base 
monad and returns not just the value, but also the security level of 
the calculated result. 

newtype DynFlowSabT ma — DynFlowSabT { 
runDynFlowSabT :: DynSL — > m (DynSL, a) 
} 

It is interesting to note the similarity with a StateT transformer 
monad carrying the program counter security level around as its 
state. This similarity does not carry through however in the instance 
of the Monad type class. 

instance (Monad m) => 

Monad (DynFlowSabT m) where 

return v — DynFlowSabT $ Ape — ► return (pc, v) 
x > y = DynFlowSabT $ Ape -¥ 
runDynFlowSabT x pc >- 
runDynFlowSabT y pc 
x / = DynFlowSabT $ Ape -> 
do (l,v) runDynFlowSabT x pc 
let xo = / v 

runDynFlowSabT xo $ max pc I 

The essence here is the security levels of the result of combined 
calculations and the security level of the program counter passed 
to the components. We make an essential difference between the 
sequence (3>) and bind (>=) operators. The first will simply drop 
the result of a left hand side calculation and not pass it on to 
the right hand side, so the result of the combined calculation is 
considered at the same security level as the right hand side result. 
Both are executed at the same program counter level. The bind 
operation is more complicated, as the value of the left calculation 
can determine not just the result of the right calculation, but can 
even result in a completely different calculation to be combined. 
Therefore we need to augment the program counter security level 
passed to the second calculation to at least the security level of the 
result of the first calculation. This perfectly reflects the rules for 
branching constructs in Sabelfeld and Russo's monitor. The return 
operation simply returns the program counter security level it is 
passed as the security level for its result. 

With these -20 lines of code, our implementation of Sabelfeld's 
monitor is almost ready. What we still need is a custom lifting 
operation which will enforce the security policy on a base monad 
calculation. It is important to note that two security levels need to 
be specified. First of all, if a base monad operation produces output 
visible at a certain security level, then we need to make sure it is 
not executed when the program counter is at a higher security level, 
because that would constitute an information leak. In addition, if 
the base monad calculation produces a result value, then we need 
to assign a correct security level to it, so that it cannot be leaked 
in the rest of the program. We will call these two security levels 
respectively the "input" (li) and "output" (lo) security levels and 
require them to be specified when a base monad operation is lifted. 

HftAt :: (Monad m) => DynSL — )■ DynSL — > m a — > 

DynFlowSabT m a 
lift At li lo c = 

let levelError pc = 

"Output at level " ■#■ show li -+f " with " -ff 
"program counter at level " 4f show pc 4f " ! " 
in DynFlowSabT $ Ape -> 

if pc < li then do v 4— c; return (lo, v) 
else fail $ levelError pc 

The functions readMail, downloadlmage, sendMail and get 
and put, can now be lifted. The function downloadResource pro- 



duces public effects and a public result, so it is lifted using the 
function lift At L L. On the contrary, readMail produces no pub- 
licly visible effects, so it can be executed with a high program 
counter level, but it produces a confidential result, so we lift with 
HftAt H H. The function sendMail is allowed to take confi- 
dential input and produces a public (unit value) result, resulting 
in HftAt H L. The String state variable is assigned a confidential 
value, leading to respectively H H and H L as input and output se- 
curity levels for the get and put functions. Note that because of the 
workings of the MonadState type class, we are limited to a single 
state variable. We have a version of the code where we remove this 
restriction and allow the user to allocate extra state variables using a 
monad transformer version of Launchbury et al.'s ST monad [10], 
but we are not going further into this because of space limitations 
and because it is unclear to us how and if this can be extended to 
the technique we will implement in section 5. 

instance (EmailM m) => 

EmailM (DynFlowSabT m) where 

downloadResource = HftAt L Lo downloadResource 
readMail = HftAt H H readMail 
sendMail = HftAt H Lo sendMail 

instance (MonadState String m) => 

MonadState String (DynFlowSabT m) where 
get = HftAt H H get 
put — HftAt H Lo put 

runpluginl = evalStateT 

(runDynFlowSabT pluginl L) "" 
runplugin2 = evalStateT 

(runDynFlowSabT plugin2 L) "" 

When we now execute the examples in GHCi, we see that our 
simple monitor works as intended, and succeeds in detecting and 
preventing the illegal information flow, while not modifying those 
executions which respect the information flow policy. 

*Main> runpluginl 

: Haskell invented currying? 

Downloading resource: http://example.com/res.txt 
Sending mail: prefix; Haskell invented currying? 

*Main> runplugin2 

: Haskell invented currying? 

*** Exception: user error (Output at level L 

with program counter at level H!) 
*Main> runplugin2 
: Some other mail contents . . . 
Sending mail: Some other mail contents... 

Our first information flow monitor monad transformer is ready. 
We have defined a basic dynamic information flow monitor as a 
monad transformer and used a special lifting function to specify 
security levels for base monad operations. In sections 5 and 6, 
we show that we can similarly implement two other information 
flow enforcement techniques. But before we continue, we first need 
to introduce a technique called parameterised monads, which we 
require for the implementation of static analysis on the user code. 

4. Parameterised Monads 

Monads in Haskell are defined through the Monad type class, 
shown in Figure 5. It defines the return, fail, (>>) and (»=) 
operations, and their type signature. For some applications, this 
type signature is too restrictive. In our case, the problem is that 
for the two enforcement techniques that we will discuss next, we 



class Monad m where 
return :: a —¥ m a 
(>■=) :: m a — > (a — > m b) — t m b 
(~3>) :: m a —¥ rn b —¥ m b 
fail :: String — > m a 



Figure 5. Definition of Monad class and its operations from the 
standard Haskell Prelude. 



import qualified Control. Monad as Old 

class Sequence m m' m" \ m m' — > m" where 

(^>) :: m a — > m' b — > m" b 
class Bind m m! rn" ram'-> m" where 

:: m a -> (a -> m' b) -> (m" 6) 
class FaiZ m where 

/aiZ :: String — > m a 
class Return m where 

returnM :: a — > m a 



Figure 6. The Sequence, Bind, Fail and Return type classes, as 
used in this paper instead of the standard Monad class. 

need to be able to keep some compile-time data about calculations 
in information flow enforcing monads. We will represent this data 
in the type of the monadic calculation, but for this, we need to 
be able to combine values of different types using the monadic 
combinators. Because this is impossible with the standard Monad 
type class, we turn to a technique that allows us to bypass this 
restriction: parameterised monads. 

Various forms of parameterised monads have been introduced, 
but for our purposes, we will use a library developed by Edward 
Kmett [9]. The basic idea in this library is to use the GHC Nolm- 
plicitPrelude [6] Haskell extension to redefine the monadic opera- 
tors in separate type classes, and to use the GHC MultiParamType- 
Classes and FunctionalDependencies extensions to allow different 
monadic types to be combined and derive the result type from the 
combined types. We go slightly further than Kmett even, by also 
separating (s>) from in separate type classes. Our definitions 
can be seen in Figure 6. 

An important consideration when using these parameterised 
monads is the impact on type inference. Because monadic calcu- 
lations of different types can now be combined, the compiler can 
no longer infer the type of one of the arguments of the (») or 
(2==) operators from the other. This would be especially problem- 
atic for the return operator, for which the type is almost always 
determined by the calculations it is sequenced or bound with, so if 
it were typed as a — > m a, then explicit programmer type ascrip- 
tion would always be required to determine the type m. 

Kmett instead proposes to type return as a — > Identity a 
with Identity the standard identity monad. In this way, less type 
inference is required to determine the type of return calls, and 
return calculations are now combined with a monad through 
the the (3>) and operators with their extended type sig- 

nature. An old-style return call is still available in the new 
type class Return under the name returnM and standard def- 
initions for Bind Identity m m, Bind m Identity m, 
Sequence m Identity rn and Sequence Identity m m are 
defined using it. The resulting definitions can be seen in Figure 7. 

It turns out that in practice, this "trick" can make parameterized 
monads feel quite natural to programmers used to standard monads 



return :: a — > Identity a 

return = Old. return 

instance Bind Identity m rn where 

Im S= f = f (runldentity Im) 
instance {Return m, Bind m m m) => 
Bind m Identity m where 
Im S= (f :: a —¥ Identity a') — 

Im >■= (returnM o runldentity o / :: a — > m a') 
instance Bind Identity Identity Identity where 

m S= / = / $ runldentity m 
instance Sequence Identity m m where 

lm> rm = rm 
instance Sequence Identity Identity Identity where 

Im 3> rm = rm 
instance (Return m, Sequence m m m) => 
Sequence m Identity m where 
Im 3> (rm :: Identity a') — 

Im ^> (returnM $ runldentity rm :: m a') 



Figure 7. Kmett's definition of the return function returning an 
instance of the Identity monad, behaves better w.r.t. type infer- 
ence. Special instances of the Bind and Sequence type classes 
make sure it interacts well with other monads. 

in Haskell. Also important in this respect is that GHC supports the 
do-notation for parameterised monads since version 6.8.3 [5], by 
simply executing the canonic translation for do-blocks in function 
of whatever versions of fail, (>>) and are in scope. 

5. Dynamic enforcement, without annotations. 

The second information flow enforcement technique we implement 
is a hybrid (dynamic, supported by static analysis) flow-sensitive 
technique developed by Le Guernic et al.[12] The technique is 
flow-sensitive, indicating that variables can be assigned different 
security levels throughout the execution of a program. The security 
levels of variables are inferred by the enforcement technique and 
do not have to be provided by the programmer. 

To present the technique, it is instructive to first consider a 
more naive attempt at getting rid of the security level annotations. 
Naively, it seems possible to just infer an appropriate security 
level for the information stored in a variable every time a value 
is assigned to it. An appropriate security level could be calculated 
as the maximum of the level of the assigned value and that of the 
program counter. We can implement special lifting functions that 
do this in our DynFlowSabT monad transformer as follows. 

instance (MonadState (DynSL, Bool) m) => 
MonadState Bool (DynFlowSabT m) where 
get — DynFlowSabT $ const get 
put v = DynFlowSabT $ Ape -> 
do put (pc, v) 
return (L, ()) 

Now, this is not very difficult to implement, but unfortunately, 
this approach is not sound, as can be seen in the following example. 

leak = do put True 

rn ^— readMail 
let p — islnteresting m 
if -i p then put False else return () 
>dopf- get 
if -i p 



then return " " 
else downloadResource res 
return () 

runleak :: (EmailM m) => m (DynSL, ()) 

runleak = evalStateT (runDynFlowSabT leak L) (L, False) 

As we can see in GHCi, the leak plugin will download the resource 
identified by URL res if a certain property of a user e-mail holds, 
thus leaking one bit of secret information and bypassing our infor- 
mation flow policy. 

*Main> runleak 

: Some other mail contents . . . 
(H,0) 

*Main> runleak 

: Haskell invented Currying? 

Downloading resource: http://example.com/res.txt 
(L,0) 

The reason that our monitor fails to detect the illegal infor- 
mation flow in this example lies in what happens in the first if- 
statement. There, if p is False, then the branch put False will be 
chosen, and our lifted put function will correctly mark the variable 
as confidential. However, in the case that p is True, no assignment 
takes place, and the security level for the state variable is not up- 
dated, even though its new value does depend on confidential data. 
Afterwards, our monitor does not consider it a problem when we 
make a request for a public resource in a branch on this variable, 
because it is marked as non-confidential. One could say that the in- 
formation leak occurs through the non-assignment of a variable in 
a conditional branch that is not executed. 

This example may seem relatively harmless at first sight, but by 
adapting the code, the trick can be exploited to consistently leak any 
amount of information, not just a single bit. In fact, our example is 
an adaptation from a classical example that plays an essential role 
in Russo and Sabelfeld's proof of the non-existence of a sound and 
precise flow-sensitive purely dynamic monitor [18]. 

Russo and Sabelfeld's result implies that a sound and precise 
flow-sensitive monitor must use some form of static analysis of 
user code. The classic example of this solution is the monitor 
developed by Le Guernic et al. [12]. They propose to tackle the 
problem by combining the dynamic tracking of state variables' 
security level with such a static analysis and an additional rule for 
conditional statements like if and while. After executing the chosen 
branch of such a statement, the monitor will in addition update 
the security level of all variables which could possibly have been 
assigned in the other branch of the conditional. This set of variables 
is precalculated using a compile-time static analysis and for all of 
these variables, the security level is increased to at least the security 
level of the program counter and the conditional expression. Le 
Guernic et al. prove that this idea effectively solves the problem 
and guarantees secure information flow. 

Clearly, what is difficult to implement about this technique in 
our framework, is the static analysis. First, it is not straightforward 
to perform such a static analysis outside of the compiler, but sec- 
ondly, we also have to generalise the rules defined by Le Guernic et 
al. to our monadic interception facilities. For the second problem, it 
turns out that Le Guernic's technique adapts nicely to our handling 
of the monadic binding operator (»=) as a generalised branch- 
ing construct. For a binding of a calculation m to a continuation / 
(m /), we will perform a static analysis of / to determine the 
complete set of variables that can be assigned by it, and update their 
security levels to at least the level of the conditional expression and 
the program counter. This update can be sequenced after the con- 
tinuation, just like Le Guernic et al. execute the updates after the 
chosen branch of an if expression. 



In order to solve the first problem (actually performing the static 
analysis of the continuation /), we apply a simple form of effect 
typing to our monadic operations. For any variable used, we define 
a ghost type, and require that it be an instance of the type class 
LGStateEffect. The function updateLabel in this class takes a 
dummy value of the ghost type and a security level, and returns a 
calculation that increases the variable's security level to at least the 
given level. Note how the functional dependency st — > m couples 
a token to the monad in which the state variable is kept. 

class LGStateEffect st m \ st — > m where 
updateLabel :: st — > DynSL — > m () 

Because a piece of code can clearly update more than a single 
state variable, we need a type-level representation for lists of to- 
kens. We define a type Nil representing the empty list and a type 
Cons parameterised by a first element of a list and a tail list. Using 
the GHC MultiParamTypeClasses, FunctionalDependencies, Over- 
lappinglnstances, Undecidablelnstances and TypeFamilies Haskell 
extensions, we define type families Add and Merge, respectively 
adding a token to a list of tokens and merging two lists, removing 
duplicate entries along the way. We also use the EmptyDataDecls 
and TypeOperators extensions for some syntactic sugar. 

data Nil 
data Cons a r 

type Singleton a — Cons a Nil 

class Add a b c \ a b — > c 

instance Add Nil a (Cons a Nil) 

instance Add (Cons a r) a (Cons a r) 

instance (Add a r r') => Add (Cons b r) a (Cons b r') 

class Merge a b c \ a b — > c 
instance Merge Nil I I 
instance (Add I a I', Merge r I' I") => 
Merge (Cons a r) I I" 

We can now instantiate the LGStateEffect class for lists of 
effects (using the Scopedtype Variables Haskell extension). 

instance LGStateEffect Nil Identity where 

updateLabel = return () 

instance (LGStateEffect t m, LGStateEffect t' m' , 
Sequence m m' m") => 
LGStateEffect (Cons t t') m" where 
updateLabel tok I — 

updateLabel (_L :: t) I ~3> 
updateLabel (_L :: t') I :: m" () 

The DynFlowLGT monad transformer is identical to the previ- 
ous DynFlowSabT, except for the annotation with the effect type 
tag: 

data DynFlowLGT t m a = DynFlowLGT { 
runDynFlowLGT :: DynSL — > m (DynSL, a) 

} 

With this, we define the function other Br anchExec, which returns 
a calculation updating the security level for all variables for which 
assignments occur in a block of code to at least a given security 
level. 

otherBranchExec :: forall t m mt ao 
(LGStateEffect t mt) 

=> DynFlowLGT t m a — > DynSL — > mt () 
otherBranchExec _ / = updateLabel (_L :: t) I 

The monadic combinators (;>) and (^=) now perform several 
tasks. In their type signature, they propagate and merge the effect 
type tags. Their implementation performs the same function as for 



the DynFlowSabT transformer, and in addition the combinator 
(2*=) employs the otherBranchExec function to update security 
levels for all variables that can possibly assigned in its right hand 
side continuation. Evidently, for the propagation of effect tokens, 
these definitions depend crucially on the parameterized monads 
introduced before. 

instance (Sequence m m! m" , Merge t t' t") => 

Sequence (DynFlowLGT t m) (DynFlowLGT t' m') 

(DynFlowLGT t" m") 
where (DynFlowLGT ex) > (DynFlowLGT ey) = 
DynFlowLGT $ \pc — > ex pc >- ey pc 

instance (Bind m mt" m" , Merge t t' t" , 
Bind m' mt' mt" , 
Sequence mt' Identity mt' , 
LGStateEffect t mt, LGStateEffect t' mt') => 
Bind (DynFlowLGT t m) (DynFlowLGT t' m') 

(DynFlowLGT t" m") where 
(DynFlowLGT x) »=/ = 
DynFlowLGT $ Ape ->■ 
do (11, Iv) <— x pc 
let rm — f Iv 

result 4— runDynFlowLGT rm $ max pc 11 
otherBranchExec rm $ max pc 11 
return result 
instance (Return m) => 

Return (DynFlowLGT t m) where 
returnM v — DynFlowLGT $ Ape — > returnM (pc, v) 

State lifting functions are now identical to the unsafe versions 
defined above, except that their results are tagged with the state 
token needed for the static analysis. Non-state operations are lifted 
as before, and get the empty list Nil as effect tag, indicating they 
do not affect any state. 

UftGet :: m (DynSL, s) DynFlowLGT t m s 
UftGet g = DynFlowLGT $ const g 

HftPut :: (Sequence m Identity m, 
LGStateEffect t m) => 
((DynSL, s) -> m ()) -> s 
-> DynFlowLGT t m () 
HftPut pv = DynFlowLGT $ Ape -> 
do p (pc, v) 

return (L, ()) 

lift At :: (Fail m, Bind m Identity m) => 

DynSL -> DynSL -> m a -J- DynFlowLGT Nil m a 
lift At li lo c = 

let levelError pc = 

"Output at level " -ff (show li) -+f " with " -ff 
"program counter at level " -ff (show pc) 4f " ! " 
in DynFlowLGT $ Ape -S- 
if pc < li 

then do v 4— c; return (max pc lo, v) 
else fail $ levelError pc 

The definitions of the API functions need to be changed because 
their type becomes more complicated with the effect annotations, 
and type inference is less powerful in the context of parameterised 
monads. Indeed, API providers need to more strongly fix the types 
of lifted base monad operations, to avoid requiring more type as- 
cription from plug-in writers. Here, we reuse the names of the lifted 
operations, so that we can keep our previous examples unmodified 
(only a recompilation required). We use the old definitions through 
a qualified import under the prefix Old. 



type BaseMonad = StateT (DynSL, String) 10 

type MonadStack t a — DynFlowLGT t BaseMonad a 

readMail :: MonadStack Nil String 
readMail = liftAt H H Old. readMail 
sendMail :: String — > MonadStack Nil () 
sendMail = liftAt H Lo Old. sendMail 
downloadResource :: String — > MonadStack Nil String 
downloadResource = liftAt L Lo Old. downloadResource 

For the state operations, we need to define an effect token ghost 
type, include the effect token in the type of the put operation, 
and instantiate the LGStateEffect type class. Again, we reuse the 
previously used get and put names. 

data VarAToken 

get :: MonadStack Nil String 
get = UftGet Old. get 

put :: String — > MonadStack (Singleton VarAToken) () 
put — HftPut Old. put 

instance (MonadState (DynSL, s) m, Bind m m m) => 
LGStateEffect VarAToken m where 
updateLabel pc — do 

(I, v) -h- Old. get :: m (DynSL, s) 

Old. put (max I pc, v) :: m () 

We can now recompile and execute our example plug-ins 
pluginl and plugin2 again. Note that we need to replace the call 
to return by a call to returnM because of the new type for return 
in our parameterised monads, and recompile the programs with the 
new definitions of the API. 

pluginl =domf- readMail 
pui$m4f "\n" 
>dop f- downloadResource res 
m <— get 

sendMail $ p -ff m 
plugm2 =domf- readMail 
put$m4f "\n" 
3> do m get 

if islnteresting m 

then downloadResource res 
else returnM " " 
sendMail m 
runpluginl :: 10 (DynSL, ()) 
runpluginl = evalStateT 

(runDynFlowLGT pluginl L) (L, "") 
runplugin2 :: 10 (DynSL, ()) 
runplugin2 = evalStateT 

(runDynFlowLGT plugin2 L) (L, "") 

When we execute these examples in GHCi, we get the expected 
results, this time without having required programmer-provided 
security level annotations for state variables. 

*Main> runpluginl 

: Haskell invented currying? 

Downloading resource: http://example.com/res.txt 
Sending mail: prefix; Haskell invented currying? 

*Main> runplugin2 

: Haskell invented currying? 

*** Exception: user error (Output at level L 

with program counter at level H!) 
*Main> runplugin2 
: Some other mail contents . . . 
Sending mail: Some other mail contents... 



Similarly, for an omitted adaptation of the leak example from 
the beginning of this section, we see that Le Guernic's solution also 
detects the illegal information flow in that example: 

*Main> runleak 

: Haskell invented currying? 

*** Exception: user error (Output at level L 

with program counter at level H!) 
*Main> runleak 

: Some other mail contents . . . 
(H,()) 

Unfortunately however, Le Guernic's technique has only been 
shown to support lexically scoped stack variables, without alias- 
ing. Features like heap data or even references cannot easily be 
supported, because they make it impossible in general to statically 
analyse the set of variables that could potentially be assigned by 
a branch of a conditional statement. In the context of real world 
API's in real world languages, we think this restriction can prove 
to be fairly strong and make the technique unusable. 



6. Static enforcement 

The third and last information flow enforcement technique we im- 
plement in this text is the classic compile-time flow-insensitive 
type-system based enforcement developed by Volpano in 1996 
[24]. Like Sabelfeld's dynamic technique (see section 3), this tech- 
nique requires programmer-provided security level annotations for 
variables and uses this to type all (pure) expressions at a certain se- 
curity level (written e : I). A subtyping rule states that if e : I and 
I < I' then e : I'. In addition to that, statements' types represent 
the lowest security level on which their effects are visible. For ex- 
ample, an assignment s to a variable annotated with security level 
I will be typed s : I cmd. Contrary to expression types, these state- 
ment types are subject to a contravariant subtyping, i.e. if s : I cmd 
and I > I' then s : I' cmd. 

Using this typing information, enforcing secure information 
flow becomes relatively easy. In assignment or output statements, 
explicit flows are prevented by requiring the assigned expression to 
be associated to the variable's security level or higher. In branching 
statements, implicit flows are prevented by requiring the security 
level of the conditional expression to be lower or equal to the effect 
levels of any of its branches. We discuss all of this in more detail in 
section 7. 

In this section, we implement this type system in a monad 
transformer, in such a way that the transformed monad behaves 
identically to the original at runtime, but the information flow 
type system is checked at compile-time. Making the security types 
part of the transformed monad calculations' types and providing 
custom types for the monad operations (as parameterized monads), 
allows us to implement the type checking in a relatively cheap way, 
making the Haskell compiler do most of the work for us. 

Clearly, the first thing we need to do to achieve this, is to rep- 
resent security levels at the type level. We use the Haskell ex- 
tensions MultiParamTypeClasses, EmptyDataDecls, TypeFamilies, 
TypeOperators and Undecidablelnstances to provide both power- 
ful, convenient and elegant type-level computation primitives for 
working with our security level types. The Undecidablelnstances 
extension is not generally accepted in the Haskell community, but 
we cannot avoid it for the static analysis we want to perform. We 
define the different levels we need as empty data types, and de- 
fine a type class • ^ •. We also define type families ■ A • and • V • 
(commonly known as join and meet operators using terminology 
from mathematical lattices), representing respectively a least upper 
bound and greatest lower bound of two security levels. 



data H 
data L 

class 11 ^ Ir 
instance H > H 
instance H ^ L 
instance i ^ L 

type family 11 A rl 
type instance H A si = H 
type instance si A H = H 
type instance L A L = L 

type family // V rl 
type instance H V H = H 
type instance slV L = L 
type instance LV si — L 

Before we continue, there is a slight extension that we need to 
make to Volpano et al.'s type system. Contrary to their model lan- 
guage, our monadic calculations can behave as both an expression 
and a statement. A base monadic calculation m v produces a re- 
sult of type v, but can also produce side effects in the background. 
This means that in the type for our transformed monad, we need to 
track both a covariant result security level representing the security 
level of the result of the calculation, and a contravariant effect se- 
curity level representing the lowest level at which it produces side 
effects. We write this as StaticFlowT Ir le m a where m is the 
base monad, v the result type, Ir the result security level and le the 
effect security level. Note that this elegant extension of Volpano et 
al.'s type system is not our contribution, but was previously inves- 
tigated by Crary et al. [3] (see section 8). We look further into the 
correspondence between the classic types and ours in section 7. 

Except for this annotation with security level types, our trans- 
formed monads are identical to the underlying base monad: 

newtype StaticFlowT Ir le m v — StaticFlowT { 
runStaticFlowT :: m v 
} 

We make our StaticFlowT monad transformer an instance of 
the MonadTrans class, so that a base monad operation can be 
lifted using the standard lift function. 

instance MonadTrans {StaticFlowT Ir le) where 
lift c — StaticFlowT c 

Note how the lifting operation is fully polymorphic in the security 
levels. The idea here is that the caller of the lift function can simply 
use explicit type ascription to annotate base monad operations 
with correct security levels. We demonstrate this for the e-mail 
application plug-in API. 

type BaseMonad = StateT String 10 
type MonadStack Ir le a = 

StaticFlowT Ir le BaseMonad a 

readMail :: MonadStack H L String 
readMail = lift Old. readMail 
sendMail :: String — ¥ MonadStack L H () 
sendMail = lift o Old. sendMail 

downloadResource :: String — > MonadStack L L String 
downloadResource = lift o Old. downloadResource 

For state variables, we lift put and get operations similarly. 

get :: MonadStack H H String 
get = lift MS. get 

put :: String — > MonadStack L H () 
put — lift o MS. put 



The final task in implementing our static information flow en- 
forcement monad transformer is defining the monadic operations: 

instance (Bind Im rm fm, rle > llr, 
llr A rlr~flr, lie V rle^fle) => 
Bind (StaticFlowT llr lie Im) 
(StaticFlowT rlr rle rm) 
(StaticFlowT fir fle fm) where 
(StaticFlowT le) »= / = 
StaticFlowT $ do x <- le; 

runStaticFlowT $ / x 
instance (Sequence Im rm fm, lie V rle^fle) => 
Sequence (StaticFlowT llr lie Im) 
(StaticFlowT rlr rle rm) 
(StaticFlowT rlr fie fm) where 
(StaticFlowT le) > (StaticFlowT re) = 
StaticFlowT % le > re 
instance (Return m) => 

Return (StaticFlowT Ir le m) where 
returnM = StaticFlowT o returnM 

These are intimidating type signatures, but before looking at 
them, it is interesting to first look what the code actually does. 
Interestingly, all that it does is pass on the monadic operations to 
the underlying monad. This is clearly what we want, since this is 
a purely compile-time enforcement technique, not performing any 
work at run-time. 

Looking at the type signatures, we see that for the monadic 
sequencing operation S>, the result security level of the left hand 
side calculation is thrown away together with the result itself, and 
the right-hand side result security level is used as the result security 
level of the calculation. Slightly less evident, the effects of the 
combined calculation are considered at the meet (minimum) of the 
effect levels of the calculations being combined. This is natural, 
since an observer at that security level can observe at least one of 
the effects. 

The monadic binding operation 3*= has an even more compli- 
cated type. The result security level of the combined calculation 
here is the join (maximum) of the levels of both calculations' re- 
sults, since both results can influence the combined result. The ef- 
fect security level is, as before the meet (minimum) of both effect 
levels. In addition to this, the 3= type signature also performs a 
check to see if the bind is actually allowed. This is done using the 
constraint rle > llr, which makes sure that information at a certain 
security level can not be used to produce effects at a lower security 
level. 

We don't repeat the pluginl and plugin2 examples, since they 
look exactly the same as in section 5. We do need to recompile 
them, because of the new definitions of the API functions, and we 
need to compile each separately, because one is supposed to give a 
compilation error and the other one isn't. 

runpluginl :: 10 () 

runpluginl — evalStateT (runStaticFlowT pluginl ) "" 

Running the runpluginl program in GHCi, the program is ac- 
cepted. The compiler statically determines that the program re- 
spects the information flow policy. Its execution is unmodified and 
does not incur any run-time overhead. 

*Main> runpluginl 

: Safe info flowing through. . . 

Downloading resource: http://example.com/res.txt 
Sending mail: prefix; Safe info flowing through... 

The runpluginl example now gives the following compile- 
time type error: 



No instance for (GT L H) 

arising from a do statement at (...) 
Possible fix: add an instance declaration for 

(GT L H) 

In a stmt of a 'do' expression: y <- getA 
In the second argument of ' (») ' , namely 
'do { y <- getA; 
if y /= 0 

then putlnt y else returnM () }' 

(...) 

We can still improve the error message a little, by playing a stan- 
dard trick on the compiler. 

data IllegallnformationFlow 
class Failure a 

instance (Failure IllegallnformationFlow) => L > H 

The improved error message has the same error location info, but 
starts like this: 

No instance for (Failure IllegallnformationFlow) 

With this, our third and last information flow enforcement 
monad transformer is also ready and working correctly on at least 
the two examples we started with. 

7. Proof 

In this text, we do not provide a proof of the correctness of all for 
the three information flow enforcement techniques we implement. 
What we do provide, in this section, is a formal result about our 
implementation of the static enforcement technique in section 6. 
What we demonstrate is that a model language and type system 
similar to the one from Volpano et al.'s presentation [24] can be 
translated into our implementation and that under this translation, 
types on both ends correspond in a precise manner that we will 
define below. It is important to note that we do not prove the 
semantic correctness of our translation, but we consider that given 
a semantically correct set of base monad state and input/output 
functions, this correctness is at least credible given the relative 
simplicity of the translation. 

Figure 8 shows the syntax of the simple model imperative pro- 
gramming language we will use. The language is the one we used 
previously in our paper about an information flow enforcement 
technique called secure multi-execution [4]. It is not the one used 
by Volpano et al., but it is similar except for the added basic input 
and output statements. Values denoted i and o represent identifiers 
of input and output channels, respectively. 

Figure 9 shows an version of the classic type system, adapted to 
our situation. These typing rules assume a fixed, user-provided as- 
signment of variables to security levels T, and fixed classifications 
<7in and (Tout of input and output channels into security levels. We 
further assume an extension of the user-provided typing for vari- 
ables to a typing for all expressions. An expression of type e : I de- 
notes an expression containing information at security level I. The 
covariant subtyping for expression types indicates that information 
at a certain security level can be used wherever more confidential 
information can. A statement typing s : I cmd denotes that the 
statement can produce effects visible on security level I. The con- 
travariant subtyping for statement types indicates that statements 
with effects at a given level can be used wherever statements with 
lower level effects can. 

Figure 11 now shows the translation function <j>, translat- 
ing a program P : I cmd in our model language to a calcu- 
lation of type StaticFlowT I L BaseMonad () (see theo- 
rem 1 below). For a program P using a set of state variables 



command ::= x :— e j c; c | if e then c else c | while e do c 
| skip input x from i output e to o 

Figure 8. Command syntax of a simple model imperative lan- 
guage. We assume a standard syntax for effect-free expressions e. 



Y{x) =1 rhe:! 
r h x := e : I cmd 

The:/ cmd T h c' : I cmd 



rhe:l 



r h q c' : 1 cmd 
fl-c:! cmd V h c' : I cmd 



r h if e then c else c' : / cmd 
The:/ The:/ cmd 
T h while e do c : / cmd 

T(x) = I <T in (i) = I 

r h input x from i : I cmd 

rhe:! CTout(o) = / 
r h output e to o : I cmd 

T h skip : / 

The: I Is^l' 
rhe:i' 
The:/ cmd I > I' 
The:/' cmd 



(1) 
(2) 

(3) 
(4) 

(5) 

(6) 
(7) 
(8) 

(9) 



Figure 9. Adapted information flow enforcement typing rules, 
based on those developed by Volpano et al [24]. Typing rules for 
expressions are assumed, reflecting the maximum security level of 
any variable used in the expression. Also assumed is a security level 
typing T for variables, based on programmer-provided variable se- 
curity level ascriptions. 



{«!,...,«„}, we assume that the variables are assigned secu- 
rity levels {1 V1 , . . . ,l Vjl }. We assume that properly typed Haskell 
values getVi :: StaticFlowT H l Vi BaseMonad Int, putVi :: 
Int — > StaticFlowT l Vi L BaseMonad () are defined. We 
assume that P uses input and output channels {ii, . . . ,i ni } and 
{oi, . . . , o„ a }, classified at security levels {U 1 , . . . , li n } and 
{l 01 , ■ ■ ■ , l 0n } and that properly typed Haskell values readlj :: 
StaticFlowT H l i} BaseMonad Int and writeOi :: Int — > 
StaticFlowT l 0i L BaseMonad () are defined. Finally, the trans- 
lation assumes a function Vars returning the set of variables used 
in a given expression, and a translation function for expressions 
4> ex , translating references to variables into references of corre- 
spondingly named Haskell values. With all of these, (f> will translate 
the given program P in a straightforward manner. Maybe the only 
unintuitive feature of this translation is the use of helper function 
upcastLeft from Figure 10, which make sure the if-statement type- 
checks by upcasting the lowest typed of the two branch statements, 
while-statements are translated to a recursive monadic expression. 

We now come to the central theorem of this section. In order to 
understand this correspondence, it is important to remark that our 
typing scheme assigns a single type to any monadic calculation, 
whereas Volpano et al. allow subtyping. For example, a calculation 
StaticFlowT L I rn () corresponds to a statement s such that 
s : I' cmd for all I' ^ I. This is taken into account in the 
formulation of the next theorem. 



upcastLeft :: StaticFlowT I L bm () — > 

StaticFlowT I' Lbm()^ 

StaticFlowT (Mm I I') L bm () 
upcastLeft a b = MkStaticFlowT (unMkStaticFlowT a) 

Figure 10. Utility function upcastLeft for use in the translation 
function <f> in Figure 1 1 . 



c = if e then c truc else Cf a i se Vars(e) = {v i% , . . . , Vi n } 

COnd = (j>ex(e) m tTUC — 0(c tr ue) Wfalsc = <^(Cfalse) 

(j){c) = getV il ^= Xv il getV ln ^= \v irl -¥ 

if cond then upcastLeft m tI uc Cfaise 
else upcastLeft mf a i sc m t rue 

(1) 



mi 



ci 



m 2 = <p(c 2 



4>(c 1 \C2) — mi 3> m 2 



(2) 



0(skip) = returnM () :: StaticFlowT H L BaseMonad () 



(3) 



c = while e do ci oop Vars(e) — {t>i, . . . , v n } 
cond — <j} ex (e) m ioop = <^(ci oop ) 

(c) = fix$ \self — > 

getVi t ^= \v il getVi n ^= \v in 

if cond then m ioop >• self else returnM () 



vol = (j) ex (e) Vars(e) = {v 1 ,... ,v n } 

4>(vi :— e) — getVi 1 \v il —»•...—> 

getVi n S= \vi n — > putVi val 



(4) 



(5) 



val 



,(e) Vars(e) = {vi,... ,v n } 



<?i(output e to Oi) = getV^ 



= \vi n — > writeOi val 



c = input vi from ij 

4>(c) = readlj S= putVi 



(6) 
(7) 



Figure 11. Translation function cf> from our model language to 
calculations in the transformed monad. 



Theorem 1. Suppose a program P as before, using variables 
{vi, . . . ,v n }. Suppose {1 V1 ,. . . , l Vn }, getVi, putV t , {ii,... ,i ni }, 
{oi, . . . ,o no }, ...,k n }, {l 01 , ...,l 0n }, readlj and writeOi, 
all as before. 

Then we have that <j>(P)\: StaticFlowT I' L BaseMonad () 
and only if P : I cmd for all I' > I. 

Proof sketch, "only if": induction on the syntactic structure of P. 

• Suppose P = if e then c true else c falso , with e : I, c truo , Cf a i S e : 
I cmd. By the induction hypothesis, we know that 0(c trU c) = 
:: StaticFlowT I' L BaseMonad (), I' > I and 
(/'(cfaise) = mfaise :: StaticFlowT I" L BaseMonad (), 
I" ^ /. Case (1) in Figure 11, the typing of the (S=) operator, 
the types of the getVi, and the assumption on the typing of 
expressions (that it is determined by the security levels of the 



variables used), together with Haskell typing rules, give us that 
4>(c):: StaticFlowT I'" L BaseMonad () with I'" ^ I. 

• Suppose P = Ci;c2, with c\ : I cmd and C2 : Zcmd. We 
know that rri\ =4>(c{)::StaticFlowT V L BaseMonad (), 
ni2 =4>(c2)y-StaticFlowT I" L BaseMonad (), for some 
/' > / and I" > I. Case (2) in Figure 11, the type of 
the (») operator and the Haskell typing rules tell us that 
4>{P):: StaticFlowT V" L BaseMonad () with V" > /. 

• The cases for skip, while, output, input are similar or straight- 
forward. 

For the "if" direction, we also work by induction on the syntac- 
tic structure of P. 

• Suppose now that P = if e then c truo else Cf a i se , that 

<p{P)\: StaticFlowT I L BaseMonad (). Take I' and I" 
such that <j)(c tIUC )::StaUcFlowT I' L BaseMonad () and 
<j>(cfaise)::StaticFlowT I" L BaseMonad (). By induction, 
case (1), the type rules for if, we know V is the same type as I", 
that 

Ctrue 5 Cfalsc 

: I'" cmd for all {Mm I' I") > I'". Because 
the security level of e is determined by the variables used in it, 
because of the types of the getVi and the (>■=) operator, we 
get that P : I"" cmd for all I > I"". 

• Suppose P — ci;C2, with mi = 4>(ci), m.2 = <fi(c2). Sup- 
pose that mi :: StaticFlowT I' L BaseMonad () and 
m,2 :: StaticFlowT I" L BaseMonad (). The type of 
the (^>) operator and Haskell typing rules then give us that 
4>{P)\: StaticFlowT I L BaseMonad () with l^Min I' I". 
Induction gives us that ci :: I'" cmd, C2 :: /"' cmd for ^ I'" 
and I" > I'" and the typing rules in our model language then 
ensure that P :: I'" cmd for all / > I'" 

• skip, while, output, input are again similar or straightforward. 

□ 

8. Discussion and Related Work 

8.1 The techniques we use 

Parameterised monads [1, 9] have already been shown to serve 
many purposes. Kiselyov uses parametrised monads for typing 
polymorphic delimited continuations [8]. Harrison and Hook also 
apply monad transformers for information flow security but in a dif- 
ferent manner. Also, our use of parameterised monads and monad 
transformers in the context of policy enforcement on Haskell li- 
braries is not new. Pucella describes an interesting implementation 
of session types using these two techniques [17]. 

8.2 The Monad operations as monitorable events in an 
information flow monitor 

In a theoretical work about fundamental limits of run-time policy 
enforcement mechanisms, Ligatti et al. [14] discuss how the set 
of events in the executing programs that can be observed by the 
monitor is one of the factors that determines the power of the 
enforcement mechanisms. In this respect, our run-time enforcement 
monad transformer from section 3 can be regarded as a monitor 
receiving only applications of the monadic bind (S=) and sequence 
(>•) operations as monitorable events. We think we have shown in 
this text that monitoring this set of events provides us with enough 
information about information flow in a program to be able to 
enforce relevant forms of secure information flow, and that we have 
been able to encode three important enforcement techniques from 
the literature. Nevertheless, we also want to point out that for at 
least one other enforcement technique, we do not believe such an 
implementation is possible. 

In section 5, we have explained the general problem related to 
flow-sensitive purely dynamic information flow monitors and Le 



Guernic's solution to this problem. Austin and Flanagan discuss an 
alternative [2], purely dynamic solution to the problem based on the 
"No Sensitive Upgrade" rule. Under this rule, it is not allowed for a 
variable's security level to be upgraded to a higher level because of 
an assignment with the program counter at a higher level. Instead, 
such an assignment will cause the program to be terminated. Our 
example leak on page 5 section 5 would thus be terminated when 
the assignment put p is executed. Austin and Flanagan prove that 
this new rule fixes the flow-sensitivity problem and ensures secure 
information flow. 

The problem for implementing this technique using our ap- 
proach can be seen by looking at how the technique handles the 
following two statements: if sec then x := true else skip and 
x := sec. Assuming that the variable x was previously assigned 
a low security level, the no sensitive upgrade rule would terminate 
the first command. The second command on the other hand is le- 
gal, and the monitor would just assign a high security level to the 
variable x. The problem now becomes apparent if we notice that in 
a monadic encoding of these examples, we get getSec >■= Xsec — > 
if sec then putX True else returnM () and getSec ;»= putX 
respectively. Notice that both cases reduce to an application of the 
monadic bind operator, making it fundamentally impossible for 
monad transformer policy enforcers to make the required distinc- 
tion. Accordingly, we believe Austin and Flanagan's enforcement 
technique cannot be implemented in our model. 

8.3 The information flow enforcement techniques we 
implement 

The information flow enforcement techniques we implement are 
classic from the literature. For an overview of existing static tech- 
niques, we refer to Sabelfeld and Myers [20] and for dynamic tech- 
niques to Le Guernic's PhD thesis [11]. 

The techniques we implement in this paper are those described 
by Sabelfeld and Russo [21] (section 3), Le Guernic et al. [12] (sec- 
tion 5) and Volpano et al. [24] (section 6). These techniques are tied 
in an important way to their handling of imperative features like 
mutable state and side effects, which is why they are relevant to 
our policy enforcement over monadic APIs. A small but neverthe- 
less relevant contribution in this paper is the way we have adapted 
these techniques to handle monadic operations. For all three of 
these techniques, the extensions followed straightforwardly from 
considering the monadic binding operator as a generalised branch- 
ing construct and generalising the rule for the if statement. Our 
presentation of Volpano et al.'s type system unified the linear type 
hierarchies for expressions and statements into a type lattice for 
monadic calculations, like in Crary et al.'s proposal [3]. 

An interesting direction for future research comes from the 
observation that monads in functional languages can be used for 
more purposes than the encoding of mutable state variables and 
side effects. Other features like exceptions and even delimited 
continuations can also be encoded in it. It would be interesting 
to investigate the application of techniques from the information 
flow literature for handling these features [15, 16, 23] by lifting the 
relevant base monad operations into information flow enforcement 
monad transformers. 

8.4 Other information flow enforcement libraries 

Finally, as an example of a Haskell information flow library, it is 
fundamental to compare our work to other interesting papers in 
this domain. Li and Zdancewic [13] were the first to propose an 
information flow enforcement library as a light-weight alternative 
to performing the enforcement as part of the implementation of 
a language compiler or interpreter. Li and Zdancewic require the 
programmer to explicitise control flow by encoding the program 
using the do-notation for arrows [7]. This is similar in spirit to 



how we approximate information flow using the invocations of 
monad operations in untrusted code. They perform a static analysis 
of the resulting dependency graph to detect illegal information 
flow, but they perform this analysis at runtime. This strikes us as a 
compromise lacking the advantages of both dynamic checking (e.g. 
determination of security levels during execution, ignoring dead 
code) and static checking (no run-time performance impact, errors 
signaled to developer during compilation). A strong point of Li and 
Zdancewic' approach is that they provide a full formal proof of the 
soundness of their enforcement. Unfortunately, they do not handle 
side effects or imperative features like mutable state, but mention 
it as interesting future work. Their use of the arrows framework 
requires the API user to work with an unfamiliar abstraction, and 
yields code that is quite strongly adapted for and as such coupled 
to their enforcement mechanism. 

Tsai, Russo and Hughes [22] improve upon Li and Zdancewic' 
work by adding support for typing separate components of struc- 
tured data differently, mutable references and concurrency primi- 
tives to the library, extending and modifying Li and Zdancewic' 
library significantly. These extensions improve the applicability of 
the library quite a bit, but they still require API users to write their 
code in the arrow abstraction. Interestingly, their FlowArrow is 
parameterised by an "underlying arrow" in a similar way as our 
monad transformers, but afterwards, they remove this generality by 
instantiating the underlying arrow with the a — > 10 b arrow when 
adding support for references. It would have been more elegant to 
use some sort of arrow transformer based on something like the ST 
monad [10]. Unlike Li and Zdancewic, Tsai, Russo and Hughes re- 
quire a type level representation of security levels (like we do in 
section 6) to keep track of the security type of the contents of refer- 
ences, and convert back to the dynamic representation a type class 
when needed in the run-time information flow analysis. This idea is 
interesting, and could perhaps be used to add support for references 
in our libraries as well. 

Russo, Claessen and Hughes present an information flow en- 
forcement library based on the more widespread monad abstraction 
instead of arrows [19]. Their approach is simple and corresponds 
quite strongly to the static enforcement technique we present in 
section 6. They use the Sec s type constructor to protect values at 
the security level represented by s, and use the SecIO s' to repre- 
sent 10 calculations producing side effects visible at security level 
s'. Their SecIO s (Sec s' v) corresponds quite strongly to the 
type StaticFlowT s' s 10 v in our implementation. 

Like Tsai, Russo and Hughes, they miss the opportunity to 
parametrise the underlying monad, instead mandating the common 
10 monad. Their Sec s and SecIO s type constructors are in- 
stances of the Monad type class, but Russo, Claessen and Hughes 
do not use the parameterised monads technique. Because of this, 
they require API users to use explicit security level casting func- 
tions (plug, up) in their programs. This is acceptable, but does not 
allow the strong separation of information flow enforcement from 
the underlying API and programs using it that parameterised mon- 
ads allow us to achieve, thus limiting the modularity of their library. 
In addition, their use of monadic values (Sec s a) as the values of 
another monad (SecIO s') requires API users to work with monads 
on two levels, which again leads to unnatural code. 

In their text, Russo, Claessen and Hughes subsequently demon- 
strate an impressive declassification framework using declassifica- 
tion combinators and the concept of escape hatches. Declassifica- 
tion is something which we have not looked at in this paper, but 
we think their declassification framework can in fact be translated 
easily to our implementations. In fact, most of their declassifica- 
tion functions can probably be reused as is by simply lifting them 
correctly into our transformed monads. This would add important 
value to our implementations, without much effort. 



We think our library improves upon this existing work in a num- 
ber of respects. First, as we have discussed, our implementations 
are much more modular, and allow for a much stronger separa- 
tion between information flow enforcement on the one hand and 
the underlying API and programs using it on the other. Second, 
this previous work never featured generality in the specific infor- 
mation flow enforcement technique used. This text, on the other 
hand, presents implementations of three different classical enforce- 
ment techniques. Third, our parameterisation in the base monad is 
more general and elegant than other libraries' use of the 10 monad. 
Finally, we think that our libraries keep the API presented very nat- 
ural to the API user, which previous approaches did not achieve, 
either due to their use of the uncommon arrow abstraction or be- 
cause of the requirement for working in more than a single monad 
and using explicit casting functions. 
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